The app opts into the scene life cycle via
application(_:configurationForConnecting:options:), which names
WordPressSceneDelegate as the scene delegate in one place for all three app
targets instead of three copies of a UIApplicationSceneManifest; the scene
delegate creates the scene-attached window and forwards every scene callback
into the AppDelegate's shared handlers. Window creation moves from
willFinishLaunching to the scene-connect phase, and launch-time URL,
user-activity, and shortcut payloads arrive through UIScene.ConnectionOptions,
routed through the same methods that handle them at runtime, so the
launchOptions plumbing is dead and removed. UITestConfigurator splits into a
process part that stays in willFinishLaunching (UI-test flags must be parsed
before the launch sequence reads them) and a window part applied when the
window is created. The unit test host's TestingAppDelegate doesn't implement
the scene opt-in, so tests keep the legacy life cycle.

AppAppearance.overrideAppearance() and the Home Screen quick action creation
both reach the app's window indirectly (the override style target and the 3D
Touch trait check). Under the scene life cycle the window does not exist until
the scene connects, so these no-opped when left in willFinishLaunching and
runStartupSequence. Move them into showInitialUI alongside the other
window-dependent launch steps.

…nnect

The system can disconnect the app's scene in the background and reconnect it
later in the same process. showInitialUI previously re-ran the full UI
bootstrap on every connect: it created a fresh window while the window manager
stayed bound to the old one (leaving the new key window empty), re-registered
the Apple ID revocation observer, and replaced the authenticator and notice
presenter. The bootstrap now runs exactly once; later connects reattach the
existing window to the new scene. The window manager's missing-window
fatalError is also downgraded to an assertion with a recovery path, since
background launches make it reachable for any unguarded UI path.

Under the scene life cycle, background launches (silent push, background URL
session wake) run with no UI and no authenticator: both are set up at the
first scene connect now. The support-notification handler built UI through
the root view coordinator, and the account-changed handler showed sign-in UI
and touched WordPressAuthenticator.shared, which fatalErrors before
configureWordPressAuthenticator runs. These paths now skip the UI and
observer work when the UI has not been built. The guards key on
hasConfiguredInitialUI rather than window presence, because the windowManager
emergency fallback can create a window while no scene has ever connected.

sceneWillEnterForeground also fires right after the initial scene connect
during a cold launch, unlike the legacy applicationWillEnterForeground, which
re-ran the Jetpack migration eligibility check and emitted its analytics
event twice per launch; the window phase already runs that check via
windowManager.showUI(). The feature flag and remote config refresh is not
skipped though: for a background-launched process, the launch-time refresh
may be hours stale by the time the user first opens the app, and an extra
refresh right after a cold launch is harmless.

A notification-tap cold launch reaches handleNotification while the
application state is still .background under the scene life cycle: the scene
has connected, but the foreground transition hasn't completed. The inactive
handler rejected that state, so the background handler swallowed the tap with
a silent sync and the app opened without navigating to the tapped
notification. The inactive handler now accepts taps in the background state,
matching the existing workaround in the authentication notification handler.